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Energy Management Framework 
Abstract 


This document defines a framework for Energy Management (EMAN) for 
devices and device components within, or connected to, communication 
networks. The framework presents a physical reference model and 
information model. The information model consists of an Energy 
Management Domain as a set of Energy Objects. Each Energy Object can 
be attributed with identity, classification, and context. Energy 
Objects can be monitored and controlled with respect to power, Power 
State, energy, demand, Power Attributes, and battery. Additionally, 
the framework models relationships and capabilities between Energy 
Objects. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7326. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 


carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 


include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Network Management is often divided into the five main areas defined 
in the ISO Telecommunications Management Network model: Fault, 
Configuration, Accounting, Performance, and Security Management 
(FCAPS) [X.700]. Not covered by this traditional management model is 
Energy Management, which is rapidly becoming a critical area of 
concern worldwide, as seen in [ISO50001]. 


This document defines an Energy Management framework for devices 
within, or connected to, communication networks, per the Energy 
Management requirements specified in [RFC6988]. The devices, or the 
components of these devices (such as line cards, fans, and disks), 
can then be monitored and controlled. Monitoring includes measuring 
power, energy, demand, and attributes of power. Energy Control can 
be performed by setting a device's or component's state. The devices 
monitored by this framework can be either of the following: 


o consumers of energy (such as routers and computer systems) and 
components of such devices (such as line cards, fans, and disks) 


o producers of energy (like an uninterruptible power supply or 
renewable energy system) and their associated components (such as 
battery cells, inverters, or photovoltaic panels) 


This framework further describes how to identify, classify, and 
provide context for such devices. While context information is not 
Specific to Energy Management, some context attributes are specified 
in the framework, addressing the following use cases: 


o How important is a device in terms of its business impact? 

o How should devices be grouped for reporting and searching? 

o How should a device role be described? 

Guidelines for using context for Energy Management are described. 


The framework introduces the concept of a Power Interface that is 
analogous to a network interface. A Power Interface is defined as an 
interconnection among devices where energy can be provided, received, 
or both. 


The most basic example of Energy Management is a single device 
reporting information about itself. In many cases, however, energy 
is not measured by the device itself but is measured upstream in the 
power distribution tree. For example, a Power Distribution Unit 
(PDU) may measure the energy it supplies to attached devices and 
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report this to an Energy Management System. Therefore, devices often 
have relationships to other devices or components in the power 
network. An Energy Management System (EnMS) generally requires an 
understanding of the power topology (who provides power to whom), the 
Metering topology (who meters whom), and the potential Aggregation 
(who aggregates values of others). 


The relationships build on the Power Interface concept. The 
different relationships among devices and components, as specified in 
this document, include power source, Metering, and Aggregation 
Relationships. 


The framework does not cover non-electrical equipment, nor does it 
cover energy procurement and manufacturing. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


In this document, these words will appear with the above 
interpretation only when in ALL CAPS.  Lowercase uses of these words 
are not to be interpreted as carrying the significance of RFC 2119 
key words. 


In this section, some terms have a NOTE that is not part of the 
definition itself but accounts for differences between terminologies 
of different standards organizations or further clarifies the 
definition. 


The terms are listed in an order that aids in reading where terms may 
build off a previous term, as opposed to an alphabetical ordering. 
Some terms that are common in electrical engineering or that describe 
common physical items use a lowercase notation. 


Energy Management 
Energy Management is a set of functions for measuring, modeling, 
planning, and optimizing networks to ensure that the network and 
network-attached devices use energy efficiently and appropriately 
for the nature of the application and the cost constraints of the 
organization. 


Reference: Adapted from [TMN]. 
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NOTES: 


1. "Energy Management" refers to the activities, methods, 
procedures, and tools that pertain to measuring, modeling, 
planning, controlling, and optimizing the use of energy in 
networked systems [NMF]. 


2. Energy Management is a management domain that is congruent to 
any of the FCAPS areas of management in the ISO/OSI Network 
Management Model [TMN]. Energy Management for communication 
networks and attached devices is a subset or part of an 
organization's greater Energy Management Policies. 


Energy Management System (EnMS) 
An Energy Management System is a combination of hardware and 
Software used to administer a network, with the primary purpose of 
Energy Management. 


NOTES: 


1. An Energy Management System according to [15050001] (ISO-EnMS) 
is a set of systems or procedures upon which organizations can 
develop and implement an energy policy, set targets and action 
plans, and take into account legal requirements related to 
energy use. An ISO-EnMS allows organizations to improve energy 
performance and demonstrate conformity to requirements, 
standards, and/or legal requirements. 


2. Example ISO-EnMS: Company A defines a set of policies and 
procedures indicating that there should exist multiple 
computerized systems that will poll energy measurements from 
their meters and pricing / source data from their local 
utility. Company A specifies that their CFO (Chief Financial 
Officer) should collect information and summarize it quarterly 
to be sent to an accounting firm to produce carbon accounting 
reporting as required by their local government. 


3. For the purposes of EMAN, the definition herein is the 
preferred meaning of an EnMS. The definition from [15050001] 
can be referred to as an ISO Energy Management System 
(ISO-EnMS). 


Energy Monitoring 
Energy Monitoring is a part of Energy Management that deals with 
collecting or reading information from devices to aid in Energy 
Management. 
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Energy Control 
Energy Control is a part of Energy Management that deals with 
directing influence over devices. 


electrical equipment 
This is a general term that includes materials, fittings, devices, 
appliances, fixtures, apparatus, machines, etc., that are used as 
a part of, or in connection with, an electric installation. 


Reference: [IEEE100]. 


non-electrical equipment (mechanical equipment) 
This is a general term that includes materials, fittings, devices, 


appliances, fixtures, apparatus, machines, etc., that are used as 
a part of, or in connection with, non-electrical power 
installations. 


Reference: Adapted from [IEEE100]. 


device 
A device is a piece of electrical or non-electrical equipment. 


Reference: Adapted from [IEEE100]. 

component 
A component is a part of electrical or non-electrical equipment 
(device). 


Reference: Adapted from [TMN]. 


power inlet 


A power inlet (or simply "inlet") is an interface at which a 
device or component receives energy from another device or 
component. 


power outlet 


A power outlet (or simply "outlet") is an interface at which a 
device or component provides energy to another device or 
component. 

energy 


Energy is that which does work or is capable of doing work. As 
used by electric utilities, it is generally a reference to 
electrical energy and is measured in kilowatt-hours (kWh). 


Reference: [IEEE100]. 
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NOTE: 


1. Energy is the capacity of a system to produce external activity 
or perform work [I5050001]. 


power 
Power is the time rate at which energy is emitted, transferred, or 
received; power is usually expressed in watts (joules per second). 


Reference: [IEEE100]. 


demand 
Demand is the average value of power or a related quantity over a 
specified interval of time. Note: Demand is expressed in 
kilowatts, kilovolt-amperes, kilovars, or other suitable units. 


Reference: [IEEE100]. 
NOTE: 


1. While IEEE100 defines demand in kilo measurements, for EMAN we 
use watts with any suitable metric prefix. 


provide energy 
A device (or component) "provides" energy to another device if 
there is an energy flow from this device to the other one. 


receive energy 
A device (or component) "receives" energy from another device if 
there is an energy flow from the other device to this one. 


meter (energy meter) 
A meter is a device intended to measure electrical energy by 
integrating power with respect to time. 


Reference: Adapted from [IEC60050]. 

battery 
A battery is one or more cells (consisting of an assembly of 
electrodes, electrolyte, container, terminals, and (usually) 
separators) that are a source and/or store of electric energy. 


Reference: Adapted from [IEC60050]. 


Power Interface 
A Power Interface is a power inlet, outlet, or both. 
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Nameplate Power 
The Nameplate Power is the nominal power of a device as specified 
by the device manufacturer. 


Power Attributes 
Power Attributes are measurements of the electrical current, 
voltage, phase, and frequencies at a given point in an electrical 
power system. 


Reference: Adapted from [IEC60050]. 
NOTE: 


1. Power Attributes are not intended to provide any bounds or 
recommended range for the value. They are simply the reading 
of the value associated with the attribute in question. 


Power Quality 
"Power Quality" refers to characteristics of the electrical 
current, voltage, phase, and frequencies at a given point in an 
electric power system, evaluated against a set of reference 
technical parameters. These parameters might, in some cases, 
relate to the compatibility between electricity supplied in an 
electric power system and the loads connected to that electric 
power system. 


Reference: [IEC60050]. 
NOTE: 


1. Electrical characteristics representing Power Quality 
information are typically required by customer facility Energy 
Management Systems. Electrical characteristics are not 
intended to satisfy the detailed requirements of Power Quality 
monitoring. Standards typically also give ranges of allowed 
values; the information attributes are the raw measurements, 
not the "yes/no" determination by the various standards. 


Reference: [ASHRAE-201]. 
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Power State 
A Power State is a condition or mode of a device (or component) 
that broadly characterizes its capabilities, power, and 
responsiveness to input. 
Reference: Adapted from [IEEE1621]. 
Power State Set 
A Power State Set is a collection of Power States that comprises a 
named or logical control grouping. 
3. Target Devices 
With Energy Management, there exists a wide variety of devices that 
may be contained in the same deployment as a communication network 
but comprise a separate facility, home, or power distribution 
network. 
Energy Management has special challenges because a power distribution 
network supplies energy to devices and components, while a separate 
communications network monitors and controls the power distribution 
network. 
The target devices for Energy Management are all devices that can be 
monitored or controlled (directly or indirectly) by an Energy 
Management System (EnMS). These target devices include, for example: 
o Simple electrical appliances and fixtures 


o Hosts, such as a PC, a server, or a printer 


o Switches, routers, base stations, and other network equipment such 
as middleboxes 


o Components within devices, e.g., a line card inside a switch 


o Batteries functioning as a device or component that is a store of 
energy 


o Devices or components that charge or produce energy, such as solar 
cells, charging stations, or generators 


o Power over Ethernet (PoE) endpoints 
o Power Distribution Units (PDUs) 


o Protocol gateway devices for Building Management Systems (BMS) 
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o Electrical meters 
o Sensor controllers with subtended sensors 


Target devices include devices that communicate via the Internet 
Protocol (IP) as well as devices using other means for communication. 
The latter are managed through gateways or proxies that can 
communicate using IP. 


4. Physical Reference Model 


The following reference model describes physical power topologies 
that exist in parallel with a communication topology. While many 
more topologies can be created with a combination of devices, the 
following are some basic ones that show how Energy Management 
topologies differ from Network Management topologies. 


NOTE: "###" is used to denote a transfer of energy. 
"- >" is used to denote a transfer of information. 


Basic Energy Management: 


Sea a a i + 
Energy Management System 
ote RSS + 
^ ^ 
monitoring | | control 
v v 
Ho + 
| device | 
Ho + 


HZ + 
| Energy Management System 
AZ + 
monitoring | | control monitoring | | control 
v v vov 
4R-------------- * 4R-----------2------ * 
| power source |4HHHBHHH | device 
4R-------------- * 4R-----------2------ * 
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Single Power Supply with Multiple Devices: 


monitoring | | control monitoring | | control 


| power |######44| device 1 | 
source | # qoc-nuscccboteuscnes dom 
decet + Add] device 2 | 
$ pasaste ES ++ 
HEHEHE | device 3 | 


| power ett] device |######| power | 
source 1 | | | | source 2 | 


5. Areas Not Covered by the Framework 


While this framework is intended as a framework for Energy Management 
in general, there are some areas that are not covered. 


Non-Electrical Equipment 


The primary focus of this framework is the management of 
electrical equipment.  Non-electrical equipment, which is not 
covered in this framework, could nevertheless be modeled by 
providing interfaces that comply with the framework: for example, 
using the same units for power and energy. Therefore, 
non-electrical equipment that does not "convert to" or 

"present as" an entity equivalent to electrical equipment is not 
addressed. 
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Energy Procurement and Manufacturing 


While an EnMS may be a central point for corporate reporting, cost 
computation, environmental impact analysis, and regulatory 
compliance reporting, Energy Management in this framework excludes 
energy procurement and the environmental impact of energy use. 


As such, the framework does not include: 


o Cost in currency or environmental units of manufacturing a 
device 


o Embedded carbon or environmental equivalences of a device 


o Cost in currency or environmental impact to dismantle or 
recycle a device 


o Supply chain analysis of energy sources for device deployment 


o Conversion of the usage or production of energy to units 
expressed from the source of that energy (such as the 
greenhouse gas emissions associated with the transfer of energy 
from a diesel source) 


6. Energy Management Abstraction 
This section describes a conceptual model of information that can be 


used for Energy Management. The classes and categories of attributes 
in the model are described, with a rationale for each. 


6.1. Conceptual Model 


This section describes an information model that addresses issues 
Specific to Energy Management and complements existing Network 
Management models. 


An information model for Energy Management will need to describe a 
means to monitor and control devices and components. The model will 
also need to describe the relationships among, and connections 
between, devices and components. 


This section defines a conceptual model for devices and components 
that is similar to the model used in Network Management: devices, 
components, and interfaces. This section then defines the additional 
attributes specific to Energy Management for those entities that are 
not available in existing Network Management models. 
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For modeling the devices and components, this section describes three 
classes denoted by a "(Class)" suffix: a Device (Class), a Component 
(Class), and a Power Interface (Class). These classes are sub-types 
of an abstract Energy Object (Class). 


Summary of Notation for Modeling Physical Equipment 


Physical Modeling (Metadata) Model Instance 
cp = Energy Object (Class) Energy Object - 
device Device (Class) Device 
component Component (Class) Component 
inlet/outlet Power Interface (Class) Power Interface 


This section then describes the attributes of an Energy Object 
(Class) for identification, classification, context, control, power, 
and energy. 


Since the interconnections between devices and components for Energy 
Management may have no relation to the interconnections for Network 
Management, the Energy Object (Classes) contain a separate 
Relationships (Class) as an attribute to model these types of 
interconnections. 


The next sections describe each of the classes and categories of 
attributes in the information model. 


Not all of the attributes are mandatory for implementations. 
Specifications describing implementations of the information model in 
this framework need to be explicit about which are mandatory and 
which are optional to implement. 


The formal definitions of the classes and attributes are specified in 
Section 7. 


6.2. Energy Object (Class) 
An Energy Object (Class) represents a piece of equipment that is 
part of, or attached to, a communications network that is monitored 


or controlled or that aids in the management of another device for 
Energy Management. 
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The Energy Object (Class) is an abstract class that contains the base 
attributes to represent a piece of equipment for Energy Management. 
There are three types of Energy Object (Class): Device (Class), 
Component (Class), and Power Interface (Class). 


6.2.1. Device (Class) 


The Device (Class) is a subclass of Energy Object (Class) that 
represents a physical piece of equipment. 


A Device (Class) instance represents a device that is a consumer, 
producer, meter, distributor, or store of energy. 


A Device (Class) instance may represent a physical device that 
contains other components. 


6.2.2. Component (Class) 


The Component (Class) is a subclass of Energy Object (Class) that 
represents a part of a physical piece of equipment. 


6.2.3. Power Interface (Class) 


A Power Interface (Class) represents the interconnections (inlet, 
outlet) among devices or components where energy can be provided, 
received, or both. 


The Power Interface (Class) is a subclass of Energy Object (Class) 
that represents a physical inlet or outlet. 


There are some similarities between Power Interfaces and network 
interfaces. A network interface can be set to different states, such 
as sending or receiving data on an attached line. Similarly, a Power 
Interface can be receiving or providing energy. 


A Power Interface (Class) instance can represent (physically) an AC 


power socket, an AC power cord attached to a device, or an 8P8C 
(RJ45) PoE socket, etc. 
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6.3. Energy Object Attributes 


This section describes categories of attributes for an Energy Object 
(Class). 


6.3.1. Identification 


A Universally Unique Identifier (UUID) [RFC4122] is used to uniquely 
and persistently identify an Energy Object. 


Every Energy Object has an optional unique human-readable printable 
name. Possible naming conventions are textual DNS name, Media Access 
Control (MAC) address of the device, interface ifName, or a text 
string uniquely identifying the Energy Object. As an example, in 

the case of IP phones, the Energy Object name can be the device's 

DNS name. 


Additionally, an alternate key is provided to allow an Energy Object 
to be optionally linked with models in different systems. 


6.3.2. Context: General 


In order to aid in reporting and in differentiation between Energy 
Objects, each object optionally contains information establishing its 
business, site, or organizational context within a deployment. 


The Energy Object (Class) contains a category attribute that broadly 
describes how an instance is used in a deployment. The category 
indicates whether the Energy Object is primarily functioning as a 
consumer, producer, meter, distributor, or store of energy. 


Given the category and context of an object, an EnMS can summarize or 
analyze measurements for the site. 


6.3.3. Context: Importance 


An Energy Object can provide an importance value in the range of 1 to 
100 to help rank a device’s use or relative value to the site. The 
importance range is from 1 (least important) to 100 (most important). 
The default importance value is 1. 


For example, a typical office environment has several types of 
phones, which can be rated according to their business impact. A 
public desk phone has a lower importance (for example, 10) than a 
business-critical emergency phone (for example, 100). As another 
example, a company can consider that a PC and a phone for a customer 
service engineer are more important than a PC and a phone for 

lobby use. 
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Although EnMS and administrators can establish their own ranking, the 
following example is a broad recommendation for commercial 
deployments [CISCO-EW]: 


90 to 100 Emergency response 

80 to 90 Executive or business-critical 
70 to 79 General or average 

60 to 69 Staff or support 

40 to 59 Public or guest 

dy 'iEG-39 Decorative or hospitality 


6.3.4. Context: Keywords 


The Energy Object (Class) contains an attribute with context 
keywords. 


An Energy Object can provide a set of keywords that is a list of tags 
that can be used for grouping, summary reporting (within or between 
Energy Management Domains), and searching. Potential examples are 
IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace, 
router, phone, floor2, or SoftwareLab. 


The specifics of how this tag is represented are left to the MIB 
module or other object definition documents to be based on this 


framework. 


There is no default value for a keyword. Multiple keywords can be 
assigned to an Energy Object. 


6.3.5. Context: Role 


The Energy Object (Class) contains a role attribute. The "role 
description" string indicates the primary purpose the Energy Object 
serves in the deployment. This could be a string representing the 


purpose the Energy Object fulfills in the deployment. 


The specifics of how this tag is represented are left to the MIB 
module or other object definition documents to be based on this 
framework. 


Administrators can define any naming scheme for the role. As 
guidance, a two-word role that combines the service the Energy Object 


provides, along with type, can be used [IPENERGY]. 


Example types of devices: Router, Switch, Light, Phone, WorkStation, 
Server, Display, Kiosk, HVAC. 
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Example Services by Line of Business: 


Line of Business Service 

raaa ^-^. students peculio Adouni strae ROOF 
Athletic 

Finance Trader, Teller, Fulfillment 

Manufacturing Assembly, Control, Shipping 

Retail Advertising, Cashier 

Support Helpdesk, Management 

Medical Patient, Administration, Billing 


Role as a two-word string: "Faculty Desktop", "Teller Phone", 
"Shipping HVAC", "Advertising Display", "Helpdesk Kiosk", 
"Administration Switch". 


The specifics of how this tag is represented are left to the MIB 
module or other object definition documents to be based on this 
framework. 


6.3.6. Context: Domain 


The Energy Object (Class) contains a string attribute to indicate 
membership in an Energy Management Domain. An Energy Management 
Domain can be any collection of Energy Objects in a deployment, but 
it is recommended to map 1:1 with a metered or sub-metered portion of 
the site. 


In building management, a meter refers to the meter provided by the 
utility used for billing and measuring power to an entire building or 
unit within a building. A sub-meter refers to a customer- or user- 
installed meter that is not used by the utility to bill but is 
instead used to get measurements from portions of a building. 


The specifics of how this tag is represented are left to the MIB 
module or other object definition documents to be based on this 


framework. 


An Energy Object MUST be a member of a single Energy Management 
Domain; therefore, one attribute is provided. 


Parello, et al. Informational [Page 17] 


RFC 7326 EMAN Framework September 2014 


6.4. Measurements 


The Energy Object (Class) contains attributes to describe power, 
energy, and demand measurements. 


An analogy for understanding power versus energy measurements can be 
made to speed and distance in automobiles. Just as a speedometer 
indicates the rate of change of distance (speed), a power measurement 
indicates the rate of transfer of energy. The odometer in an 
automobile measures the cumulative distance traveled; similarly, an 
energy measurement indicates the accumulated energy transferred. 


Demand measurements are averages of power measurements over time. 

So, using the same analogy to an automobile: measuring the average 
vehicle speed over multiple intervals of time for a given distance 
traveled, demand is the average power measured over multiple time 

intervals for a given energy value. 


Within this framework, energy will only be quantified in units of 
watt-hours. Physical devices measuring energy in other units must 
convert values to watt-hours or be represented by Energy Objects that 
convert to watt-hours. 


6.4.1. Measurements: Power 


The Energy Object (Class) contains a Nameplate Power Attribute that 
describes the nominal power as specified by the manufacturer of the 
device. The EnMS can use the Nameplate Power for provisioning, 
capacity planning, and (potentially) billing. 


The Energy Object (Class) has attributes that describe the present 
power information, along with how that measurement was obtained or 
derived (e.g., actual, estimated, or static). 


A power measurement is qualified with the units, magnitude, and 
direction of power flow and is qualified as to the means by which the 
measurement was made. 


Power measurement magnitude conforms to the [IEC61850] definition of 
unit multiplier for the SI (System International) units of measure. 
Measured values are represented in SI units obtained by BaseValue * 
(10 ^ Scale). For example, if current power usage of an Energy 
Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 MW, depending on 
the value of the scaling factor. 17 W implies that BaseValue - 17 
and Scale = 0, whereas 17 mW implies that BaseValue = 17 and 
ScaleFactor - -3. 
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An Energy Object (Class) indicates how the power measurement was 
obtained with a caliber and accuracy attribute that indicates: 


o Whether the measurements were made at the device itself or at a 
remote source. 


o Description of the method that was used to measure the power and 
whether this method can distinguish actual or estimated values. 


O Accuracy for actual measured values. 

6.4.2. Measurements: Power Attributes 
The Energy Object (Class) contains an optional attribute that 
describes Power Attribute information reflecting the electrical 


characteristics of the measurement. These Power Attributes adhere to 
the [IEC61850-7-2] standard for describing AC measurements. 


6.4.3. Measurements: Energy 


The Energy Object (Class) contains optional attributes that represent 
the energy used, received, produced, and/or stored. Typically, only 
devices or components that can measure actual power will have the 
ability to measure energy. 


6.4.4. Measurements: Demand 


The Energy Object (Class) contains optional attributes that represent 
demand information over time. Typically, only devices or components 
that can report actual power are capable of measuring demand. 


6.5. Control 


The Energy Object (Class) contains a Power State Set (Class) 
attribute that represents the set of Power States a device or 
component supports. 


A Power State describes a condition or mode of a device or component. 
While Power States are typically used for control, they may be used 
for monitoring only. 


A device or component is expected to support at least one set of 
Power States consisting of at least two states: an on state and an 
off state. 


There are many existing standards describing device and component 


Power States. The framework supports modeling a mixed set of Power 
States defined in different standards. A basic example is given by 
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the three Power States defined in IEEE1621 [IEEE1621]: on, off, and 
Sleep. The Distributed Management Task Force (DMTF) standards 
organization [DMTF], Advanced Configuration and Power Interface 
(ACPI) specification [ACPI], and Printer Working Group (PWG) all 
define larger numbers of Power States. 


The semantics of a Power State are specified by: 
a) The functionality provided by an Energy Object in this state. 


b) A limitation of the power that an Energy Object uses in this 
state. 


C) A combination of a) and b). 

The semantics of a Power State should be clearly defined. Limitation 
(curtailment) of the power used by an Energy Object in a state may be 
Specified by: 


o An absolute power value. 


O A percentage value of power relative to the Energy Object's 
Nameplate Power. 


o An indication of power relative to another Power State. For 
example, specify that power in state A is less than in state B. 


o For supporting Power State management, an Energy Object provides 
statistics on Power States, including the time an Energy Object 
spent in a certain Power State and the number of times an Energy 
Object entered a Power State. 


When requesting an Energy Object to enter a Power State, an 
indication of the Power State's name or number can be used. 
Optionally, an absolute or percentage of Nameplate Power can be 
provided to allow the Energy Object to transition to a nearest or 
equivalent Power State. 


When an Energy Object is set to a particular Power State, the 
represented device or component may be busy. The Energy Object 
should set the desired Power State and then update the actual Power 
State when the device or component changes. There are then two Power 
State (Class) control attributes: actual and requested. 


The following sections describe well-known Power States for devices 
and components that should be modeled in the information model. 
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6.5.1. Power State Sets 
There are several standards and implementations of Power State Sets. 
The Energy Object (Class) supports modeling one or multiple Power 


State Set implementations on the device or component concurrently. 


There are currently three Power State Sets specified by IANA: 


IEEE1621 (256) - [IEEE1621] 
DMTF (512) - [DMTF] 
EMAN (768) - [RFC7326] 


The respective specific states related to each Power State Set are 
Specified in the following sections. The guidelines for the 
modification of Power State Sets are specified in the IANA 
Considerations section. 


6.5.2. Power State Set: IEEE1621 


The IEEE1621 Power State Set [IEEE1621] consists of three rudimentary 
states: on, off, or sleep. 


In IEEE1621, devices are limited to the three basic Power States -- 


on (2), sleep (1), and off (0). Any additional Power States are 
variants of one of the basic states, rather than a fourth state 
[IEEE1621]. 


6.5.3. Power State Set: DMTF 


The DMTF [DMTF] standards organization has defined a power profile 
standard based on the CIM (Common Information Model), which consists 
of 15 Power States. 


The DMTF standard is targeted for hosts and computers. Details of 
the semantics of each Power State within the DMTF Power State Set can 
be obtained from the DMTF Power State Management Profile 
Specification [DMTF]. 
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The DMTF power profile extends ACPI Power States. The following 
table provides a mapping between DMTF and ACPI Power State Sets: 


Reserved (0) 
Reserved (1) 


ON (2) G0/S0 
Sleep-Light (3) G1/S1 G1/S2 
Sleep-Deep (4) G1/83 
Power Cycle (Off-Soft) (5) G2/85 
Off-Hard (6) G3 
Hibernate (Off-Soft) (7) G1/S4 
Off-Soft (8) G2/S5 
Power Cycle (Off-Hard) (9) G3 
Master Bus Reset (10) G2/85 
Diagnostic Interrupt (11) G2/85 
Off-Soft Graceful (12) G2/S5 
Off-Hard Graceful (13) G3 
MasterBus Reset Graceful (14) G2/S5 
Power Cycle Off-Soft Graceful (15) G2/S5 
Power Cycle Off-Hard Graceful (16) G3 


4. Power State Set: IETF EMAN 


The EMAN Power States are an expansion of the basic Power States as 
defined in [IEEE1621] plus the addition of the Power States defined 
in [ACPI] and [DMTF]. Therefore, in addition to the non-operational 
states as defined in [ACPI] and [DMTF] standards, several 
intermediate operational states have been defined. 


Physical devices and components are expected to support the EMAN 
Power State Set or to be modeled via an Energy Object the supports 
these states. 


An Energy Object may implement fewer or more Power States than a 
particular EMAN Power State Set specifies. In that case, the Energy 
Object implementation can determine its own mapping to the predefined 
EMAN Power States within the EMAN Power State Set. 


There are twelve EMAN Power States that expand on [IEEE1621]. The 
expanded list of Power States is derived from [CISCO-EW] and is 
divided into six operational states and six non-operational states. 
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The lowest non-operational state is 0, and the highest is 5. Each 
non-operational state corresponds to an [ACPI] Global and System 
state between G3 (hard-off) and Gl (sleeping). Each operational 


state represents a performance state and may be mapped to [ACPI] 
states PO (maximum performance power) through P5 (minimum performance 
and minimum power). 


In each of the non-operational states (from mechoff(0) to ready(5)), 
the Power State preceding it is expected to have a lower Power value 
and a longer delay in returning to an operational state: 


mechoff(0): An off state where no Energy Object features are 
available. The Energy Object is unavailable. No energy is 
being consumed, and the power connector can be removed. 


softoff(1): Similar to mechoff(0), but some components remain 
powered or receive trace power so that the Energy Object can be 
awakened from its off state. In softoff(1), no context is 
saved, and the device typically requires a complete boot when 
awakened. 


hibernate(2): No Energy Object features are available. The Energy 
Object may be awakened without requiring a complete boot, but 
the time for availability is longer than sleep(3). An example 
for state hibernate(2) is a save-to-disk state where DRAM 
context is not maintained. Typically, energy consumption is 
zero or close to zero. 


sleep(3): No Energy Object features are available, except for 
out-of-band management, such as wake-up mechanisms. The time 
for availability is longer than standby(4). An example for 
state sleep(3) is a save-to-RAM state, where DRAM context is 
maintained. Typically, energy consumption is close to zero. 


standby(4): No Energy Object features are available, except for 
out-of-band management, such as wake-up mechanisms. This mode 
is analogous to cold-standby. The time for availability is 
longer than ready(5). For example, processor context may not 
be maintained. Typically, energy consumption is close to zero. 


ready(5): No Energy Object features are available, except for 
out-of-band management, such as wake-up mechanisms. This mode 
is analogous to hot-standby. The Energy Object can be quickly 
transitioned into an operational state. For example, 
processors are not executing, but processor context is 
maintained. 
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lowMinus(6): Indicates that some Energy Object features may not be 
available and the Energy Object has taken measures or selected 
options to use less energy than low(7). 


low(7): Indicates that some Energy Object features may not be 
available and the Energy Object has taken measures or selected 
options to use less energy than mediumMinus(8). 


mediumMinus (8): Indicates that all Energy Object features are 
available but the Energy Object has taken measures or selected 
options to use less energy than medium(9). 


medium(9): Indicates that all Energy Object features are available 
but the Energy Object has taken measures or selected options to 
use less energy than highMinus (10). 


highMinus(10): Indicates that all Energy Object features are 
available and the Energy Object has taken measures or selected 
options to use less energy than high(11). 


high(11): Indicates that all Energy Object features are available 
and the Energy Object may use the maximum energy as indicated 
by the Nameplate Power. 


6.5.5. Power State Sets Comparison 


A comparison of Power States from different Power State Sets can be 
seen in the following tables: 


Non-operational states: 


IEEE1621  DMTF ACPI EMAN 
off Off-Hard G3/S5 mechoff (0) 
off Off-Soft G2/S5 softoff(1) 
off Hibernate G1/S4 hibernate (2) 
sleep Sleep-Deep G1/S3 sleep (3) 
sleep Sleep-Light G1/S2 standby (4) 
sleep Sleep-Light G1/S1 ready (5) 
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Operational states: 


IEEE1621 DMTF ACPI EMAN 

on on G0/S0/P5 lowMinus (6) 

on on G0/S0/P4 low (7) 

on on G0/S0/P3 mediumMinus (8) 
on on G0/S0/P2 medium(9) 

on on G0/S0/P1 highMinus (10) 
on on G0/S0/PO0 high (11) 


6.6. Relationships 


The Energy Object (Class) contains a set of Relationship (Class) 
attributes to model the relationships between devices and components. 
Two Energy Objects can establish an Energy Object Relationship to 
model the deployment topology with respect to Energy Management. 


Relationships are modeled with a Relationship (Class) that contains 
the UUID of the other participant in the relationship and a name that 
describes the type of relationship [CHEN]. The types of 
relationships are Power Source, Metering, and Aggregations. 


o A Power Source Relationship is a relationship where one Energy 
Object provides power to one or more Energy Objects. The Power 
Source Relationship gives a view of the physical wiring topology 
-- for example, a data center server receiving power from two 
Specific Power Interfaces from two different PDUs. 


Note: A Power Source Relationship may or may not change as the 
direction of power changes between two Energy Objects. The 
relationship may remain to indicate that the change of power 
direction was unintended or an error condition. 


o A Metering Relationship is a relationship where one Energy Object 
measures power, energy, demand, or Power Attributes of one or more 
other Energy Objects. The Metering Relationship gives the view of 
the Metering topology. Physical meters can be placed anywhere in 
a power distribution tree. For example, utility meters monitor 
and report accumulated power consumption of the entire building. 
Logically, the Metering topology overlaps with the wiring 
topology, as meters are connected to the wiring topology. A 
typical example is meters that clamp onto the existing wiring. 
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o An Aggregation Relationship is a relationship where one Energy 
Object aggregates Energy Management information of one or more 
other Energy Objects. The Aggregation Relationship gives a model 
of devices that may aggregate (sum, average, etc.) values for 
other devices. The Aggregation Relationship is slightly different 
compared to the other relationships, as this refers more to a 
management function. 


In some situations, it is not possible to discover the Energy Object 
Relationships, and an EnMS or administrator must set them. Given 
that relationships can be assigned manually, the following sections 
describe guidelines for use. 


6.6.1. Relationship Conventions and Guidelines 


This Energy Management framework does not impose many "MUST" rules 
related to Energy Object Relationships. There are always corner 
cases that can be excluded by making stricter specifications for 
relationships. However, the framework proposes a series of 
guidelines, indicated with "SHOULD" and "MAY". 


6.6.2. Guidelines: Power Source 


Power Source Relationships are intended to identify the connections 
between Power Interfaces. This is analogous to a Layer 2 connection 
in networking devices (a "one-hop connection"). 


The preferred modeling would be for Power Interfaces to participate 
in Power Source Relationships. In some cases, Energy Objects may not 
have the capability to model Power Interfaces. Therefore, a Power 
Source Relationship can be established between two Energy Objects or 
two non-connected Power Interfaces. 


Strictly speaking, while components and Power Interfaces on the same 
Device do provide or receive energy from each other, the Power Source 
Relationship is intended to show energy transfer between Devices. 
Therefore, the relationship is implied when on the same Device. 


An Energy Object SHOULD NOT establish a Power Source Relationship 
with a component. 


o A Power Source Relationship SHOULD be established with the next 
known Power Interface in the wiring topology. 
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o The next known Power Interface in the wiring topology would be the 


next device implementing the framework. In some cases, the domain 
of devices under management may include some devices that do not 
implement the framework. In these cases, the Power Source 


Relationship can be established with the next device in the 
topology that implements the framework and logically shows the 
Power Source of the device. 


o Transitive Power Source Relationships SHOULD NOT be established. 
For example, if Energy Object A has a Power Source Relationship 
"Poweredby" with Energy Object B, and if Energy Object B has a 
Power Source Relationship "Poweredby" with Energy Object C, then 
Energy Object A SHOULD NOT have a Power Source Relationship 
"Poweredby" with Energy Object C. 


6.6.3. Guidelines: Metering Relationship 


Metering Relationships are intended to show when one device acting as 
a meter is measuring the power or energy at a point in a power 
distribution system. Since one point of a power distribution system 
may cover many devices within a wiring topology, this relationship 
type can be seen as a set. 


Some devices may include hardware that can measure power for 
components, outlets, or the entire device. For example, some PDUs 
may have the ability to measure power for each outlet and are 


commonly referred to as metered-by-outlet. Others may be able to 
control power at each power outlet but can only measure power at the 
power inlet -- commonly referred to as metered-by-device. 


While the Metering Relationship could be used to represent a device 
as metered-by-outlet or metered-by-device, the Metering Relationship 
SHOULD be used to model the relationship between a meter and all 
devices covered by the meter downstream in the power distribution 
system. 


In general: 


o A Metering Relationship MAY be established with any other Energy 
Object, component, or Power Interface. 


o Transitive Metering Relationships MAY be used. 
o When there is a series of meters for one Energy Object, the Energy 


Object MAY establish a Metering Relationship with one or more of 
the meters. 
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6.6.4. Guidelines: Aggregation 


Aggregation Relationships are intended to identify when one device is 
used to accumulate values from other devices. Typically, this is for 
energy or power values among devices and not for components or Power 
Interfaces on the same device. 


The intent of Aggregation Relationships is to indicate when one 
device is providing aggregate values for a set of other devices when 
it is not obvious from the power source or simple containment within 
a device. 


Establishing Aggregation Relationships within the same device would 
make modeling more complex, and the aggregated values can be implied 
from the use of power inlets, outlet, and Energy Object values on the 
same device. 


Since an EnMS is naturally a point of Aggregation, it is not 
necessary to model Aggregation for Energy Management Systems. 


The Aggregation Relationship is intended for power and energy. It 
MAY be used for Aggregation of other values from the information 
model, but the rules and logical ability to aggregate each attribute 
are out of scope for this document. 


In general: 


o A Device SHOULD NOT establish an Aggregation Relationship with 
components contained on the same device. 


o A Device SHOULD NOT establish an Aggregation Relationship with the 
Power Interfaces contained on the same device. 


o A Device SHOULD NOT establish an Aggregation Relationship with an 
EnMS. 


o Aggregators SHOULD log or provide notification in the case of 
errors or missing values while performing Aggregation. 
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6.6.5. Energy Object Relationship Extensions 


This framework for Energy Management is based on three relationship 
types: Aggregation, Metering, and Power Source. 


This framework is defined with possible future extension of new 
Energy Object Relationships in mind. 


For example: 


o Some Devices that may not be IP connected could be modeled with a 
proxy relationship to an Energy Object within the domain. This 
type of proxy relationship is left for further development. 


o A Power Distribution Unit (PDU) that allows devices and components 
like outlets to be "ganged" together as a logical entity for 
simplified management purposes could be modeled with an extension 
called a "gang relationship", whose semantics would specify the 
Energy Objects' grouping. 


7. Energy Management Information Model 


This section presents an information model expression of the concepts 
in this framework as a reference for implementers. The information 
model is implemented as MIB modules in the different related IETF 
EMAN documents. However, other programming structures with different 
data models could be used as well. 


Data modeling specifications of this information model may, where 
needed, specify which attributes are required or optional. 


Syntax 


Unified Modeling 

Language (UML) 

Construct 

[ISO-IEC-19501-2005] Equivalent Notation 


Notes // Notes 
Class 

(Generalization) CLASS name í(member..) 
Subclass 

(Specialization) CLASS subclass 


EXTENDS superclass (member..) 
Class Member 
(Attribute) attribute : type 
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Model 
CLASS EnergyObject { 


// identification / classification 


index 2 int 
name : string 
identifier : uuid 
alternatekey : string 


// context 


domainName : string 
role : string 
keywords [0..n] : string 
importance : int 


// relationship 
relationships [0..n] : Relationship 


// measurements 


nameplate : Nameplate 

power : PowerMeasurement 
energy : EnergyMeasurement 
demand : DemandMeasurement 


// control 
powerControl [0..n] : PowerStateSet 


CLASS PowerInterface EXTENDS EnergyObject { 
eolfType : enum { inlet, outlet, both } 


CLASS Device EXTENDS EnergyObject { 


eocategory : enum { producer, consumer, meter, 
distributor, store } 

powerInterfaces [0..n] : PowerInterface 

components [0..n] : Component 


} 


CLASS Component EXTENDS EnergyObject { 


eocategory : enum { producer, consumer, meter, 
distributor, store } 

powerInterfaces [0..n] : PowerInterface 

components [0..n] : Component 
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CLASS Nameplate { 
nominalPower : PowerMeasurement 
details : URI 

} 


CLASS Relationship { 


relationshipType : enum ( meters, meteredby, powers, 
poweredby, aggregates, aggregatedby } 
relationshipObject : uuid 


} 


CLASS Measurement { 
multiplier : enum { -24..24 } 
caliber : enum { actual, estimated, static } 
accuracy : enum { 0..10000 } // hundreds of percent 


CLASS PowerMeasurement EXTENDS Measurement { 
value : long 
units TW 
powerAttribute : PowerAttribute 


CLASS EnergyMeasurement EXTENDS Measurement { 


startTime : time 
units : "kWh" 
provided : long 
used : long 
produced : long 
stored : long 


CLASS TimedMeasurement EXTENDS Measurement { 


startTime : timestamp 
value : Measurement 
maximum : Measurement 


CLASS TimeInterval { 
value : long 
units : enum ( seconds, milliseconds,... ) 
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CLASS DemandMeasurement EXTENDS Measurement { 


intervalLength : TimeInterval 

intervals : long 

intervalMode : enum ( periodic, sliding, total ) 
intervalWindow : TimeInterval 

sampleRate : TimeInterval 

status : enum { active, inactive } 
measurements [0..n] : TimedMeasurements 


CLASS PowerStateSet { 


powerSetIdentifier : int 

name : string 
powerStates [0..n] : PowerState 
operState : NE 
adminState s int 

reason : string 
configuredTime : timestamp 


CLASS PowerState { 


powerStateldentifier : int 

name : string 
cardinality : int 

maximumPower : PowerMeasurement 
totalTimeInState : time 

entryCount : long 


CLASS PowerAttribute { 
acQuality : ACQuality 


CLASS ACQuality { 


acConfiguration : enum { SNGL, DEL, WYE } 
avgVoltage : long 
avgCurrent : long 
thdCurrent : long 
frequency : long 
unitMultiplier : int 
accuracy STINE 
totalActivePower : long 
totalReactivePower : long 
totalApparentPower : long 
totalPowerFactor : long 
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CLASS DelPhase EXTENDS ACQuality { 
phaseToNextPhaseVoltage : long 
thdVoltage : long 


CLASS WYEPhase EXTENDS ACQuality { 
phaseToNeutralVoltage : long 


thdCurrent : long 
thdVoltage : long 
avgCurrent : long 


} 
8. Modeling Relationships between Devices 


In this section, we give examples of how to use the EMAN information 
model to model physical topologies. Where applicable, we show how 
the framework can be applied when devices can be modeled with Power 
Interfaces. We also show how the framework can be applied when 
devices cannot be modeled with Power Interfaces but only monitored or 
controlled as a whole. For instance, a PDU may only be able to 
measure power and energy for the entire unit without the ability to 
distinguish among the inlets or outlets. 


8.1. Power Source Relationship 
The Power Source Relationship is used to model the interconnections 
between devices, components, and/or Power Interfaces to indicate the 


source of energy for a device. 


In the following examples, we show variations on modeling the 
reference topologies using relationships. 


Given for all cases: 


Device W: A computer with one power supply. Power Interface 1 is an 
inlet for Device W. 


Device X: A computer with two power supplies. Power Interface 1 and 
Power Interface 2 are both inlets for Device X. 


Device Y: A PDU with multiple Power Interfaces numbered 0..10. Power 
Interface 0 is an inlet, and Power Interfaces 1..10 are outlets. 


Device Z: A PDU with multiple Power Interfaces numbered 0..10. Power 
Interface 0 is an inlet, and Power Interfaces 1..10 are outlets. 
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Case 1: Simple Device with one Source 
Physical Topology: 
o Device W inlet 1 is plugged into Device Y outlet 8. 
With Power Interfaces: 


o Device W has an Energy Object representing the computer 
itself as well as one Power Interface defined as an inlet. 


o Device Y would have an Energy Object representing the PDU 
itself (the Device), with Power Interface 0 defined as an 


inlet and Power Interfaces 1..10 defined as outlets. 


The interfaces of the devices would have a Power Source 
Relationship such that: 


Device W inlet 1 is powered by Device Y outlet 8. 
Ho T------ + poweredBy +------ ASES SA + 
PDU Y | PI 8 |----------------- | PI 1 | Device W 
4------- 4------ t powers 4------ 4---------- + 
Without Power Interfaces: 
o Device W has an Energy Object representing the computer. 
o Device Y would have an Energy Object representing the PDU. 


The devices would have a Power Source Relationship such that: 


Device W is powered by Device Y. 
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Case 2: Multiple Inlets 


Physical Topology: 


o 


o 


Device X inlet 1 is plugged into Device Y outlet 8. 


Device X inlet 2 is plugged into Device Y outlet 9. 


With Power Interfaces: 


o 


Device X has an Energy Object representing the computer 


itself. It contains two Power Interfaces defined as inlets. 


Device Y would have an Energy Object representing the PDU 
itself (the Device), with Power Interface 0 defined as an 
inlet and Power Interfaces 1..10 defined as outlets. 


The interfaces of the devices would have a Power Source 
Relationship such that: 


Device X inlet 1 is powered by Device Y outlet 8. 


Device X inlet 2 is powered by Device Y outlet 9. 


T------- Ha => + poweredBy+------ HL + 
| | PI 8 |----------------- | PI 1 | | 
| | | powers | | | 
PDU Y +------ t poweredBy+------ + Device X 
| PI 9 |----------------- | PI2 | 
| | | powers | | | 
T------- T------ t T------ 4---------- t 


Without Power Interfaces: 


Parello, 


o 


Device X has an Energy Object representing the computer. 
Device Y has an Energy Object representing the PDU. 


The devices would have a Power Source Relationship such that: 


Device X is powered by Device Y. 
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Case 3: Multiple Sources 
Physical Topology: 
o Device X inlet 1 is plugged into Device Y outlet 8. 
o Device X inlet 2 is plugged into Device Z outlet 9. 
With Power Interfaces: 


o Device X has an Energy Object representing the computer 
itself. It contains two Power Interfaces defined as inlets. 


o Device Y would have an Energy Object representing the PDU 
itself (the Device), with Power Interface 0 defined as an 
inlet and Power Interfaces 1..10 defined as outlets. 

o Device Z would have an Energy Object representing the PDU 
itself (the Device), with Power Interface 0 defined as an 


inlet and Power Interfaces 1..10 defined as outlets. 


The interfaces of the devices would have a Power Source 
Relationship such that: 


Device X inlet 1 is powered by Device Y outlet 8. 


Device X inlet 2 is powered by Device Z outlet 9. 


qEsesccs S + poweredByt-----—-t----—-—----— + 

| PDU Y | PI 8 |----------------- [PT A | 

| | | powers | | | 

4------- 4------ + 4------ + | 
| Device X | 

Ho T------ t poweredBy+------ + 

| PDU z | PI 9 |----------------- | PI 2 | 

| | | powers | | | 

4------- 4------ + 4+------ 4+---------- + 


Without Power Interfaces: 
o Device X has an Energy Object representing the computer. 


Devices Y and Z would both have respective Energy Objects 
representing each entire PDU. 
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The devices would have a Power Source Relationship such that: 


Device X is powered by Device Y and powered by Device Z. 


== ==>====2 + poweredBy t------------ + 
PDU Y _ |--------------------- | Device X | 
pmeee—e——-- + powers qpeseneeee-——— + 
F======5=2=5 + poweredBy t-----------— t 
| PDUZ | --------------------- | Device X 
FEOS AS + powers ASAS E + 


8.2. Metering Relationship 


A meter in a power distribution system can logically measure the 
power or energy for all devices downstream from the meter in the 
power distribution system. As such, a Metering Relationship can be 
Seen as a relationship between a meter and all of the devices 
downstream from the meter. 


We define in this case a Metering Relationship between a meter and 
devices downstream from the meter. 


T----- ++ meteredBy.:4=3====== E poweredBy t*------- + 
|Meter| P1I|-------------- | switch |------------- | phone | 
(=== +---+ meters +=>===5==> + powers — 
| 
| meteredBy | 
c b ae eee t 
meters 


In cases where the Power Source topology cannot be discovered or 
derived from the information available in the Energy Management 
Domain, the Metering topology can be used to relate the upstream 
meter to the downstream devices in the absence of specific Power 
Source Relationships. 
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A Metering Relationship can occur between devices that are not 
directly connected, as shown in the following figure: 


+--------------- + 

| Device 1 | 

4--------------- t 

| PI | 

+--------------- + 

+--------------- + 

Meter 

+--------------- + 
meters meters meters 
4---------- t T4---------- + +----------- + 
| Device A | | Device B | | Device c | 
+---------- + +---------- + +----------- + 


An analogy to communications networks would be modeling connections 
between servers (meters) and clients (devices) when the complete 
Layer 2 topology between the servers and clients is not known. 


8.3. Aggregation Relationship 


Some devices can act as Aggregation points for other devices. For 
example, a PDU controller device may contain the summation of power 
and energy readings for many PDU devices. The PDU controller will 
have aggregate values for power and energy for a group of PDU 
devices. 


This Aggregation is independent of the physical power or 
communication topology. 


The functions that the Aggregation point may perform include the 
calculation of values such as average, count, maximum, median, 
minimum, or the listing (collection) of the Aggregation values, etc. 


Based on IETF experience gained on Aggregations [RFC7015], the 
Aggregation function in the EMAN framework is limited to the 
summation. 


When Aggregation occurs across a set of entities, values to be 
aggregated may be missing for some entities. The EMAN framework does 
not specify how these should be treated, as different implementations 
may have good reason to take different approaches. One common 
treatment is to define the Aggregation as missing if any of the 
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constituent elements are missing (useful to be most precise). 
Another is to treat the missing value as zero (useful to have 
continuous data streams). 


The specifications of Aggregation functions are out of the scope of 
the EMAN framework but must be clearly specified by the equipment 


vendor. 


9. Relationship to Other Standards 


This Energy Management framework uses, as much as possible, existing 
standards, especially with respect to information modeling and data 
modeling [RFC3444]. 


The data model for power- and energy-related objects is based on 
[IEC61850]. 


Specific examples include: 


o The scaling factor, which represents Energy Object usage 
magnitude, conforms to the [IEC61850] definition of unit 
multiplier for the SI (System International) units of measure. 


o The electrical characteristics are based on the ANSI and IEC 
Standards, which require that we use an accuracy class for power 
measurement.  ANSI and IEC define the following accuracy classes 
for power measurement: 


- IEC 62053-22 and 60044-1 classes 0.1, 0.2, 0.5, 1, and 3. 
— ANSI C12.20 classes 0.2 and 0.5. 


o The electrical characteristics and quality adhere closely to the 
[IEC61850-7-4] standard for describing AC measurements. 


o The Power State definitions are based on the DMTF Power State 
Profile and ACPI models, with operational state extensions. 


10. Security Considerations 


Regarding the data attributes specified here, some or all may be 
considered sensitive or vulnerable in some network environments. 
Reading or writing these attributes without proper protection such as 
encryption or access authorization will have negative effects on 
network capabilities. Event logs for audit purposes on configuration 
and other changes should be generated according to current 
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10. 


authorization, audit, and accounting principles to facilitate 
investigations (compromise or benign misconfigurations) or any 
reporting requirements. 


The information and control capabilities specified in this framework 
could be exploited, to the detriment of a site or deployment. 
Implementers of the framework SHOULD examine and mitigate security 
threats with respect to these new capabilities. 


"User-based Security Model (USM) for version 3 of the Simple Network 
Management Protocol (SNMPv3)" [RFC3414] presents a good description 
of threats and mitigations for SNMPv3 that can be used as a guide for 
implementations of this framework using other protocols. 


1. Security Considerations for SNMP 


Readable objects in MIB modules (i.e., objects with a MAX-ACCESS 
other than not-accessible) may be considered sensitive or vulnerable 
in some network environments. It is important to control GET and/or 
NOTIFY access to these objects and possibly to encrypt the values of 
these objects when sending them over the network via SNMP. 


The support for SET operations in a non-secure environment without 
proper protection can have a negative effect on network operations. 


For example: 


o Unauthorized changes to the Energy Management Domain or business 
context of a device will result in misreporting or interruption of 
power. 


o Unauthorized changes to a Power State will disrupt the power 
settings of the different devices and therefore the state of 
functionality of the respective devices. 


o Unauthorized changes to the demand history will disrupt proper 
accounting of energy usage. 


With respect to data transport, SNMP versions prior to SNMPv3 did not 
include adequate security. Even if the network itself is secure (for 
example, by using IPsec), there is still no secure control over who 
on the secure network is allowed to access and GET/SET 
(read/change/create/delete) the objects in these MIB modules. 


It is recommended that implementers consider the security features as 
provided by the SNMPv3 framework (see [RFC3411]), including full 
support for the SNMPv3 cryptographic mechanisms (for authentication 
and confidentiality). 
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Further, deployment of SNMP versions prior to SNMPv3 is not 
recommended. Instead, it is recommended to deploy SNMPv3 and to 
enable cryptographic security. It is then a customer/operator 
responsibility to ensure that the SNMP entity giving access to an 
instance of these MIB modules is properly configured to give access 
to the objects only to those principals (users) that have legitimate 
rights to GET or SET (change/create/delete) them. 


11.  IANA Considerations 


11.1.  IANA Registration of New Power State Sets 


This document specifies an initial set of Power State Sets. The list 
of these Power State Sets with their numeric identifiers is given in 
Section 6. IANA maintains the lists of Power State Sets. 


New assignments for a Power State Set are administered by IANA 
through Expert Review [RFC5226], i.e., review by one of a group of 
experts designated by an IETF Area Director. The group of experts 
must check the requested state for completeness and accuracy of the 
description. A pure vendor-specific implementation of a Power State 
Set shall not be adopted, since it would lead to proliferation of 
Power State Sets. 


Power States in a Power State Set are limited to 255 distinct values. 
A new Power State Set must be assigned the next available numeric 
identifier that is a multiple of 256. 


11.1.1.  IANA Registration of the IEEE1621 Power State Set 


This document specifies a set of values for the IEEE1621 Power State 
Set [IEEE1621]. The list of these values with their identifiers is 
given in Section 6.5.2. IANA created a new registry for IEEE1621 
Power State Set identifiers and filled it with the initial list of 
identifiers. 


New assignments (or, potentially, deprecation) for the IEEE1621 Power 
State Set are administered by IANA through Expert Review [RFC5226]. 


11.1.2.  IANA Registration of the DMTF Power State Set 


This document specifies a set of values for the DMTF Power State Set 
[DMTF]. The list of these values with their identifiers is given in 
Section 6.5.3. IANA has created a new registry for DMTF Power State 
Set identifiers and filled it with the initial list of identifiers. 


New assignments (or, potentially, deprecation) for the DMTF Power 
State Set are administered by IANA through Expert Review [RFC5226]. 
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The group of experts must check for conformance with the DMTF 
standard [DMTF] in addition to checking for completeness and accuracy 
of the description. 


11.1.3.  IANA Registration of the EMAN Power State Set 


This document specifies a set of values for the EMAN Power State Set. 
The list of these values with their identifiers is given in 

Section 6.5.4. IANA has created a new registry for EMAN Power State 
Set identifiers and filled it with the initial list of identifiers. 


New assignments (or, potentially, deprecation) for the EMAN Power 
State Set are administered by IANA through Expert Review [RFC5226]. 


11.2. Updating the Registration of Existing Power State Sets 


With the evolution of standards, over time, it may be important to 
deprecate some of the existing Power State Sets, or to add or 
deprecate some Power States within a Power State Set. 


The registrant shall post an Internet-Draft with the clear 
specification on deprecation of Power State Sets or Power States 
registered with IANA. The deprecation or addition shall be 
administered by IANA through Expert Review [RFC5226], i.e., review by 
one of a group of experts designated by an IETF Area Director. The 
process should also allow for a mechanism for cases where others have 
Significant objections to claims regarding the deprecation of a 
registration. 
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A. 


r 


rw 


rw 


rw 


rw 


rw 


rw 


EnergyObject (Class): 


index Integer 
name String 
identifier uuid 


alternatekey String 


domainName String 
role String 
keywords String 
importance Integer 


relationships Relationship 
[0..n] 


nameplate Nameplate 

power PowerMeasurement 
energy EnergyMeasurement 
demand DemandMeasurement 


Information Model Listing 
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An [RFC6933] entPhysicalIndex 
An [RFC6933] entPhysicalName 
An [RFC6933] entPhysicalUUID 
A manufacturer-defined string 


that can be used to identify the 
Energy Object 


The name of an Energy Management 
Domain for the Energy Object 


An administratively assigned name 
to indicate the purpose an 

Energy Object serves in the 
network 


A list of keywords or [0..n] tags 
that can be used to group Energy 
Objects for reporting or 
searching 


Specifies a ranking of how 
important the Energy Object is 
(on a scale of 1 to 100) compared 
with other Energy Objects 


A list of relationships between 
this Energy Object and other 
Energy Objects 


The nominal PowerMeasurement of 
the Energy Object as specified by 
the device manufacturer 


The present power measurement of 
the Energy Object 


The present energy measurement 
for the Energy Object 


The present demand measurement 
for the Energy Object 
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r powerControl PowerStateSet A list of Power States Sets the 
[0..n] Energy Object supports 


B. PowerInterface (Class) inherits from EnergyObject: 


r eoIfType Enumeration Indicates whether the Power 
Interface is an inlet, outlet, 
or both 


C. Device (Class) inherits from EnergyObject: 


rw eocategory Enumeration Broadly indicates whether 
the Device is a producer, 
consumer, meter, distributor, 
or store of energy 


r powerInterfaces PowerInterface A list of PowerInterfaces 


[0..n] contained in this Device 
r components Component A list of components 
[0..n] contained in this Device 


D. Component (Class) inherits from EnergyObject: 


rw eocategory Enumeration Broadly indicates whether the 
component is a producer, 
consumer, meter, distributor, or 
store of energy 


r powerInterfaces  PowerInterface A list of PowerInterfaces 


[0..n] contained in this component 
r components Component A list of components contained 
[0..n] in this component 
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E. 


r 


rw 


rw 


rw 


Parel 


326 


Nameplate (Class): 
nominalPower 
details URI 
Relationship (Class): 
relationshipType 
relationshipObject 
Measurement (Class): 
multiplier Enumeration 
caliber Enumeration 
accuracy Enumeration 
PowerMeasurement 
value Long 
units "W" 
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PowerMeasurement The nominal power of the Energy 


(Class) 


as specified by the device 
manufacturer 


An [RFC3986] URI that links to 
manufacturer information about 
the nominal power of a device 


Enumeration A description of the 


relationship, indicating 
meters, meteredby, powers, 
poweredby, aggregates, or 
aggregatedby 


An [RFC6933] entPhysicalUUID 
that indicates the other 
participating Energy Object in 
the relationship 


The magnitude of the Measurement 
in the range -24..24 


Specifies how the Measurement was 
obtained -- actual, estimated, or 
static 


Specifies the accuracy of the 
measurement, if applicable, as 
0..10000, indicating hundreds of 
percent 


inherits from Measurement: 


A measurement value of 
power 


The units of measure for 
the power -- "Watts" 
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Measurement of the electrical 
current -- voltage, phase, and/or 
frequencies for the 
PowerMeasurement 


I. EnergyMeasurement (Class) inherits from Measurement: 
r startTime Time Specifies the start time of the 
EnergyMeasurement interval 
r units "kWh" The units of measure for the energy -- 
kilowatt-hours 
r provided Long A measurement of energy provided 
r used Long A measurement of energy used/consumed 
r produced Long A measurement of energy produced 
r stored Long A measurement of energy stored 
J. TimedMeasurement (Class) inherits from Measurement: 
r startTime timestamp A start time of a measurement 
r value Measurement A measurement value 
r maximum Measurement A maximum value measured since a previous 
timestamp 
K. Timelnterval (Class): 
r value Long A value of time 
r units Enumeration A magnitude of time, expressed as seconds 
with an SI prefix (milliseconds, etc.) 
L. DemandMeasurement (Class) inherits from Measurement: 
rw intervalLength  TimeInterval The length of time over which to 
compute average energy 
rw intervals Long The number of intervals that can 
be measured 
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rw intervalMode Enumeration The mode of interval 
measurement -- periodic, sliding, 
or total 
rw intervalWindow  TimeInterval The duration between the starting 
time of one sliding window and 
the next starting time 
rw sampleRate TimeInterval The sampling rate at which to 
poll power in order to compute 
demand 
rw status Enumeration A control to start or stop demand 
measurement -- active or inactive 
r measurements TimedMeasurement A collection of TimedMeasurements 
[0..n] to compute demand 
M. PowerStateSet (Class): 
r powerSetIdentifier Integer An IANA-assigned value indicating 
a Power State Set 
r name String A Power State Set name 
r powerStates PowerState A set of Power States for the 
[0..n] given identifier 
rw operState Integer The current operational Power 
State 
rw adminState Integer The desired Power State 
rw reason String Describes the reason 
for the adminState 
r configuredTime timestamp Indicates the time of 
the desired Power State 
N. PowerState (Class): 
r powerStateIdentifier Integer An IANA-assigned value 
indicating a Power State 
r name String A name for the Power State 
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r cardinality 


rw maximumPower 


r totalTimeInState 


H 


entryCount 
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Integer 


A value indicating an 
ordering of the Power State 


PowerMeasurement Indicates the maximum power 


Time 


Long 


O. PowerAttribute (Class): 


r acQuality 


P. ACQuality (Class): 


r acConfiguration 


r avgVoltage 


r avgCurrent 


r thdCurrent 


r frequency 


r unitMultiplier 


Parello, et al. 


ACQuality 


Enumeration 


Long 


Long 


Long 


Long 


Integer 


for the Energy Object at 
this Power State 


Indicates the total time 

an Energy Object has been 
in this Power State since 
the last reset 


Indicates the number of 
times the Energy Object 
has entered or changed to 
this state 


Describes AC Power Attributes for 
a Measurement 


Describes the physical 
configuration of alternating 
current as single phase (SNGL), 
three-phase delta (DEL), or 
three-phase Y (WYE) 


The average of the voltage measured 
over an integral number of AC 
cycles [IEC61850-7-4] 'Vol' 


The current per phase 
[IEC61850-7-4] ‘Amp’ 


A calculated value for the current 
Total Harmonic Distortion (THD). 
The method of calculation is not 
Specified [IEC61850-7-4] ’ThdAmp’ 


Basic frequency of the AC circuit 
[IEC61850-7-4] 'Hz' 


Magnitude of watts for the usage 
value in this instance 
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r accuracy Integer Percentage value in 100ths 
of a percent, representing the 
presumed accuracy of active, 
reactive, and apparent power 
in this instance 


r totalActivePower Long A measured value of the actual 
power delivered to or consumed by 
the load [IEC61850-7-4] 'TotW' 


r totalReactivePower Long A measured value of the reactive 
portion of the apparent power 
[IEC61850-7-4] 'TotVAr' 


r totalApparentPower Long A measured value of the voltage 
and current, which determines the 
apparent power as the vector sum of 
real and reactive power 
[IEC61850-7-4] 'TotVA' 


r totalPowerFactor Long A measured value of the ratio of 
the real power flowing to the load 
versus the apparent power 
[IEC61850-7-4] 'TotPF” 


Q. DelPhase (Class) inherits from ACQuality: 


r phaseToNext Long A measured value of phase to 
PhaseVoltage next phase voltages where the 
next phase is [IEC61850-7-4] 
'pPPV' 
r thdVoltage Long A calculated value for the 


voltage Total Harmonic Distortion 
(THD) for phase to next phase. 
The method of calculation is not 
Specified [IEC61850-7-4] 'ThdPPV' 
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R. WYEPhase 


EMAN Framework September 


(Class) inherits from ACQuality: 


r phaseToNeutral Long 
Voltage 


r thdCurrent 


r thdVoltage 


r avgCurrent 


Parello, 


et al. 


Long 


Long 


Long 


A measured value of phase to 
neutral voltage [IEC61850-7-4] 
' PhV' 


A calculated value for the current 
Total Harmonic Distortion (THD). 
The method of calculation is not 
Specified [IEC61850-7-4] 'ThdA' 


A calculated value of the voltage 
THD for phase to neutral 
[IEC61850-7-4] 'ThdPhV” 


A measured value of phase currents 
[IEC61850-7-4] 'A' 
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